On 9/4/2025 12:17 PM, Mike Terry wrote:
On 04/09/2025 04:25, Kaz Kylheku wrote:
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,
Please do not attempt to bluster your way through
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.
On 9/3/2025 10:25 PM, Kaz Kylheku wrote:
I think I can very nicely articulate the main thing that is leading
Peter astray.
_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]
DD emulated by any HHH according to the semantics of
the x86 language cannot possibly reach past its own
machine address of 0000216b thus cannot possibly
reach its own correctly emulated "ret" instruction
and halt.
Any disagreement is the same as saying that 2 + 3 = π
objectively counter-factual.
On 2025-09-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
Or if you'd said there is a "potentially infinite" tower I'd have been happier, although I'd still
The thing is, I believe that in the nested simulation, any condition
that is evaluated before the "pull the plug" catastrophic event holds
true of a version of that universe in which the plug is never pulled on
any simulation.
If we somehow correctly detect that successive nested simulations are identical, we can conclude by induction that we have a repeating
pattern: all subsequent levels are the same.
Now if we make that obseravtion before ceasing any simulation, then that result should hold true in a universe in which simulations are never abandoned.
Suppose that we used parallel processing units of some kind of for the simulations. For each simulations, we allocate a new simulating machine
that runs in parallel, like an independent processor. Initially we
operate it it in single step mode and look for the abort pattern in lock step. When we notice the pattern, we switch the simulator to
free-running mode to continue its simulation and detach from it, then
return 0.
This situation clearly gives us the infinite tower; no simulation is
actually stopped, so each simulation begets another one, ad infinitum.
Up until the point that the original in-line version of the simulation
pulls the plug, whatever it calculates should be identical to the
situation with parallel simulations that are never canceled. Any truth
that it correctly deduces should be true of the infinity.
Anyway, my main point was that Olcott conflated the detection of the
infinity (whether that be correct or not) with the idea that it
indicates that DD does not terminate, making HHD(DD) -> 0 a correct
answer. (Whereupon he needs the handwaving to explain why a top-level
call to DD() terminates: that is the "caller" of HHH, and not its
"actual input" that is "correctly simulated").
On 2025-09-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
Or if you'd said there is a "potentially infinite"
tower I'd have been happier, although I'd still
The thing is, I believe that in the nested simulation, any condition
that is evaluated before the "pull the plug" catastrophic event holds
true of a version of that universe in which the plug is never pulled on
any simulation.
If we somehow correctly detect that successive nested simulations are identical, we can conclude by induction that we have a repeating
pattern: all subsequent levels are the same.
Now if we make that obseravtion before ceasing any simulation, then that result should hold true in a universe in which simulations are never abandoned.
Suppose that we used parallel processing units of some kind of for the simulations. For each simulations, we allocate a new simulating machine
that runs in parallel, like an independent processor. Initially we
operate it it in single step mode and look for the abort pattern in lock step. When we notice the pattern, we switch the simulator to
free-running mode to continue its simulation and detach from it, then
return 0.
This situation clearly gives us the infinite tower; no simulation is
actually stopped, so each simulation begets another one, ad infinitum.
Up until the point that the original in-line version of the simulation
pulls the plug, whatever it calculates should be identical to the
situation with parallel simulations that are never canceled. Any truth
that it correctly deduces should be true of the infinity.
Anyway, my main point was that Olcott conflated the detection of the
infinity (whether that be correct or not) with the idea that it
indicates that DD does not terminate, making HHD(DD) -> 0 a correct
answer. (Whereupon he needs the handwaving to explain why a top-level
call to DD() terminates: that is the "caller" of HHH, and not its
"actual input" that is "correctly simulated").
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
If the question is:
Does Infinite_Recursion correctly simulated by HHH
ever stop running?
The answer is yes.
The correct question is:
Does Infinite_Recursion correctly simulated
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Only the above question is the correct halting
problem question.
On 08/09/2025 21:08, olcott wrote:
<snip>
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
If the question is:
Does Infinite_Recursion correctly simulated by HHH
ever stop running?
Well, that's not the question.
The question is whether the program terminates. Clearly, it doesn't.
The answer is yes.
Then HHH is clearly screwed.
The correct question is:
Does Infinite_Recursion correctly simulated
That is a question that interests only one person very much.
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Who cares?
On 9/8/2025 3:42 PM, Richard Heathfield wrote:
On 08/09/2025 21:08, olcott wrote:
The correct question is:
Does Infinite_Recursion correctly simulated
That is a question that interests only one person very much.
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Who cares?
It is a single unifying measure that always
takes ever relevant detail into account.
Newbies think that halting is stopping running
for any reason.
Halting is actually reaching a
final halt state. Whenever this is impossible
then non-halting is definitely specified.
Why do we have to measure this by simulating
the input instead of just seeing if the program
reaches its final halt state when run?
Because all deciders only report on the semantic
or syntactic property of their inputs. By measuring
the halt status by simulating the input we get the
actual behavior of the actual input not the behavior
of some non-input.
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:
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,
Please do not attempt to bluster your way through
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
and because "DD emulated
by some HHH" may mean either that thequestion is about the same
code as is used by "some HHH" in emulation or that it is about
the emulation of DD by "some HHH". If the question is answered
without noticing the ambiquity then it is possible that the
answer is to an interpretation of the question that differs from
the intended interpretation. If the ambiguity is noticed then
the right thing is to change the question to a clearer one that
might mean what the original was intended to mean and then to
answer that question.
If we somehow correctly detect that successive
nested simulations are identical, we can conclude
by induction that we have a repeating pattern:
all subsequent levels are the same.
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:
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,
Please do not attempt to bluster your way through
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.
On 08/09/2025 23:01, olcott wrote:
On 9/8/2025 3:42 PM, Richard Heathfield wrote:
On 08/09/2025 21:08, olcott wrote:
<snip>
The correct question is:
Does Infinite_Recursion correctly simulated
That is a question that interests only one person very much.
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Who cares?
It is a single unifying measure that always
takes ever relevant detail into account.
No, sir, it is not. For example, it fails to take into account the observation that your simulation is known to return erroneous results on occasion.
Newbies think that halting is stopping running
for any reason.
Even newbiers think that DD doesn't halt, when all you have to do to
find out whether it halts is to run it. Clearly HHH is doomed to get
this wrong, but even a casual inspection of the source code will show
that a return of 0 from HHH will end DD. You *cannot* get that wrong...
but you do. Clearly your observational ability is at fault.
Halting is actually reaching a
final halt state. Whenever this is impossible
then non-halting is definitely specified.
When HHH returns 0 to its caller (which you insist it does), DD returns
to its caller.
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would
stop running on its own without intervention. That this intervention is required indicates that even DD() cannot be said to actually halt.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input
is all that it can see.
If we wanted to get HHH to examine the behavior of its caller then weWhat? DD called from main() definitely halts, otherwise HHH wouldn't
can do it this way.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determines
that DD() executed from main() does not halt.
On 9/8/2025 9:29 PM, Richard Heathfield wrote:
On 08/09/2025 23:01, olcott wrote:
On 9/8/2025 3:42 PM, Richard Heathfield wrote:
On 08/09/2025 21:08, olcott wrote:
<snip>
The correct question is:
Does Infinite_Recursion correctly simulated
That is a question that interests only one person very much.
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Who cares?
It is a single unifying measure that always
takes ever relevant detail into account.
No, sir, it is not. For example, it fails to take into account
the observation that your simulation is known to return
erroneous results on occasion.
DD() is essentially the same as if itself specifies
infinite recursion that is aborted after its second
recursive call.
The directly executed DD() itself would never stop
running unless aborted at some point.
Because of
this
we cannot say that DD() would stop running on
its own without intervention.
That this intervention
is required indicates that even DD() cannot be said
to actually halt.
When HHH returns 0 to its caller (which you insist it does), DD
returns to its caller.
HHH is only assessing the semantic property of its input
because its input is all that it can see.
Now that HHH can see DD() executed from main HHH
correctly determines that DD() executed from main()
does not halt.
On 09/09/2025 16:00, olcott wrote:
On 9/8/2025 9:29 PM, Richard Heathfield wrote:
On 08/09/2025 23:01, olcott wrote:
On 9/8/2025 3:42 PM, Richard Heathfield wrote:
On 08/09/2025 21:08, olcott wrote:
<snip>
The correct question is:
Does Infinite_Recursion correctly simulated
That is a question that interests only one person very much.
by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Who cares?
It is a single unifying measure that always
takes ever relevant detail into account.
No, sir, it is not. For example, it fails to take into account the
observation that your simulation is known to return erroneous results
on occasion.
DD() is essentially the same as if itself specifies
infinite recursion that is aborted after its second
recursive call.
No, it isn't essentially anything of the kind. At no point does DD
specify recursion. It never calls itself, and it doesn't call any
functions that call it. There Is No Recursion.
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would
stop running on its own without intervention. That this intervention is
required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its own.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input
is all that it can see.
Neither the name of a function nor the input on its own define anything.
If we wanted to get HHH to examine the behavior of its caller then we
can do it this way.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determinesWhat? DD called from main() definitely halts, otherwise HHH wouldn't
that DD() executed from main() does not halt.
even run, and now HHH also "reports on its caller".
When HHH is allowed to see the behavior of the
directly executed DD() HHH proves that DD()
is non halting.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH
correctly determines that DD() executed from main()
does not halt.
On 9/4/2025 4:16 PM, Kaz Kylheku wrote:
On 2025-09-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
Or if you'd said there is a "potentially infinite"
tower I'd have been happier, although I'd still
The thing is, I believe that in the nested simulation, any condition
that is evaluated before the "pull the plug" catastrophic event holds
true of a version of that universe in which the plug is never pulled on
any simulation.
If we somehow correctly detect that successive nested simulations are
identical, we can conclude by induction that we have a repeating
pattern: all subsequent levels are the same.
Yes.
Now if we make that obseravtion before ceasing any simulation, then that
result should hold true in a universe in which simulations are never
abandoned.
Yes.
Suppose that we used parallel processing units of some kind of for the
simulations. For each simulations, we allocate a new simulating machine
that runs in parallel, like an independent processor. Initially we
operate it it in single step mode and look for the abort pattern in lock
step. When we notice the pattern, we switch the simulator to
free-running mode to continue its simulation and detach from it, then
return 0.
That is overly convoluted and seems to diverge from the point.
That would be a correct assessment.
Yes.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
If the question is:
Does Infinite_Recursion correctly simulated by HHH
ever stop running? The answer is yes.
The correct question is:
Does Infinite_Recursion correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
Only the above question is the correct halting
problem question.
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would
stop running on its own without intervention. That this intervention is
required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its own.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input
is all that it can see.
Neither the name of a function nor the input on its own define anything.
If we wanted to get HHH to examine the behavior of its caller then we
can do it this way.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determinesWhat? DD called from main() definitely halts, otherwise HHH wouldn't
that DD() executed from main() does not halt.
even run, and now HHH also "reports on its caller".
On 2025-09-08, olcott <polcott333@gmail.com> wrote:
On 9/4/2025 4:16 PM, Kaz Kylheku wrote:
On 2025-09-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
Or if you'd said there is a "potentially infinite"
tower I'd have been happier, although I'd still
The thing is, I believe that in the nested simulation, any condition
that is evaluated before the "pull the plug" catastrophic event holds
true of a version of that universe in which the plug is never pulled on
any simulation.
If we somehow correctly detect that successive nested simulations are
identical, we can conclude by induction that we have a repeating
pattern: all subsequent levels are the same.
Yes.
Now if we make that obseravtion before ceasing any simulation, then that >>> result should hold true in a universe in which simulations are never
abandoned.
Yes.
Suppose that we used parallel processing units of some kind of for the
simulations. For each simulations, we allocate a new simulating machine
that runs in parallel, like an independent processor. Initially we
operate it it in single step mode and look for the abort pattern in lock >>> step. When we notice the pattern, we switch the simulator to
free-running mode to continue its simulation and detach from it, then
return 0.
That is overly convoluted and seems to diverge from the point.
Is it convoluted? Or is it just a threat to your narrative?
You could implement a threading system like this:
1. Have SimulationManager module/object which manages an array of
simulations that are in progress.
2. When x86utm starts, SimulationManager is initialized with a list
that contains one simulation: a simulation which calls main().
3. The SimulationManager sits in a loop, going round-robin over
the list of simulations, stepping each one. Whenever a simulation
terminates, it removes itfrom the list.
4. Nothing but the SimulationManager runs simulations. Provide an API
to the SimulationManager whereby a clien tmodule can request a
new simulation to be created.
5. Allow newly created simualtions to be created in a suspended state,
whereby the SimulationManager keeps them in the list, but ignores
them. This allows the client itself to single-step the simulation.
6. Provide an API by which the client can indicate that
suspended/stepped simulation should be free running. Then
the simulation manager goes back to stepping it.
With these ingredients, you can easily write a HHH which creates
a simulation with the Simulation Manager API for that purpose,
in a suspended state in which HHH itself controls the stepping.
When HHH sees some situation that causes it to return 0, it
informs the SimulationManager that the simulation should
be free running. Then it returns 0.
You can do this without any thread scheduling kernel. You already have
the virtual CPU logic for creating software threads!
You don't need inter-process communication mechanisms or anything,
because ... your simulations are not supposed to communicate;
that would be cheating anyway.
I'm not sure how I/O is handled in your simulation system (for issuing
print statements to the console).
Would mutual exclusion be needed for
that under the Simulation Manager? Maybe it could just have logic
whereby if it detects that if a machine is running a library function
like printf, it keeps single stepping just that machine until it returns
out of the library, and only then switches to the next machine in the round-robin queue.
In other words, the core library of your system is treated as a kind of kernel; when the machines call it, they have trapped into the kernel,
and like old Unix kernels, the kernel is single-processor,
non-preemptable. Nothing else executes while a task is in kernel space
until it bails out of kernel space. Of course, you must not use the
kernel for cheating.
[...]
That would be a correct assessment.
[...]
Yes.
OK, we have a pattern here of you agreeing with all my assessments,
which is refreshing.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
If the question is:
Does Infinite_Recursion correctly simulated by HHH
ever stop running? The answer is yes.
So, obviously, /that/ would never be the halting problem
question, we again agree (and that could be the extended 'we'
of everyone in the debate).
The correct question is:
Does Infinite_Recursion correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state? The answer is no.
And there we have it: your point of view distilled into the simplest
form.
Let's put your definition to the test.
Your personal definition of the Halting Problem question is that every decider must test whether the HHH decider, when simulating the input,
would allow it to reach a return statement.
Suppose I write a decider called GGG, and a function CC:
void CC(void)
{
if (GGG(CC)) { for (;;); }
else { return; }
}
So, the "correct" question is: does GGG(CC), correctly simulated by HHH, reach its return statement?
Suppose that GGG(CC) is such that it returns 0. Thus, CC() reaches
the return statement, right?
Since CC() reaches its return statement, we expect HHH(CC) to return 1.
So 1 is the correct answer to the question.
But GGG(CC) is producing the wrong answer 0.
Can we fix it? What can we do other than to redefine GGG(CC)
sot hat it returns 1.
But now we have a CC() that deos not reach its return statement, when it
is correctly simulated by HHH. So HHH(CC) must return the correct answer
0. Problem is since that's the correct answer, GGG(CC) is getting it
wrong by returning 1.
Your correction to the Halting Problem question fixes HHH, but other
deciders keep falling, showing there is no universal halting decider.
What is your plan here? For every proposed decider, are you going to
change what the correct question is? For instance, is it your idea that
for the above GGG, we can have the following "correct" question:
"Does the input, correctly simulated by GGG, reach its simulated
return statement?"
Only the above question is the correct halting
problem question.
Making a special exception for a cherry-picked HHH decider doesn't help.
All you are doing by redefining the question is casting doubt on your
work by raising the possibility that you're not writing about the real Halting Problem.
On 09/09/2025 16:26, joes wrote:
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would
stop running on its own without intervention. That this intervention is
required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its own.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input
is all that it can see.
Neither the name of a function nor the input on its own define anything.
If we wanted to get HHH to examine the behavior of its caller then weWhat? DD called from main() definitely halts, otherwise HHH wouldn't
can do it this way.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determines
that DD() executed from main() does not halt.
even run, and now HHH also "reports on its caller".
Yeah, it's strange - main() begins at 00002241 so PO's x86utm output for sure would have started from that address. And yet somehow that's not showing in the output he posted, almost as though PO has edited that
output to trick everybody, thinking we're total idiots who wouldn't spot such a trick! PO's output mysteriously starts at 00002249 - how did the processor get there!?
Conspiricy!! Conspiricy!!
----------------------- --------------------- | | | |
| PUBLISH THE FULL | | WE DEMAND *ALL* |
| OUTPUT! | | THE TRACE | | |----| |
-----------------------RAIN---------------------
| | THE | |
| | SWAMP! | |
| ----------- |
| | |
| | |
0/ O | \O
/| /|\| |\
/ \ / \ / \
Mike.
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
On 9/9/2025 12:30 PM, Kaz Kylheku wrote:
Your personal definition of the Halting Problem question is that every
decider must test whether the HHH decider, when simulating the input,
would allow it to reach a return statement.
Yes.
Suppose I write a decider called GGG, and a function CC:
void CC(void)
{
if (GGG(CC)) { for (;;); }
else { return; }
}
So, the "correct" question is: does GGG(CC), correctly simulated by HHH,
reach its return statement?
I just empirically tested it: I changed GGG to HHH.
same result.
Suppose that GGG(CC) is such that it returns 0. Thus, CC() reaches
the return statement, right?
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE ALWAYS TALKING ABOUT THE BEHAVIOR OF CC SIMULATED BY GGG
The correct question is:
Does [whatever] correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state?
Making a special exception for a cherry-picked HHH decider doesn't help.
All you are doing by redefining the question is casting doubt on your
work by raising the possibility that you're not writing about the real
Halting Problem.
The semantic property of the input finite string to GGG(CC)
is not halting.
No decider has ever been able to do anything
besides compute the mapping FROM ITS ACTUAL INPUT FINITE STRING
to the syntactic or semantic property specified by this INPUT
FINITE STRING. This mistake has apparently been perpetuated
since 1936.
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about
the Halting Problem.
When you can simulate the whole thing, maybe then you'll have something
to talk about, but right now you can only simulate one lousy line (and
you get that wrong).
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The
behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about
the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see has always contradicted the definition
of Turing machine deciders that only compute the
mapping from their input finite strings.
When you can simulate the whole thing, maybe then you'll have
something to talk about, but right now you can only simulate one lousy
line (and you get that wrong).
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us
are. The behaviour of a decider that can't see the code it's
deciding is not really all that interesting, as it has nothing
to say whatsoever about the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 12:30 PM, Kaz Kylheku wrote:
Your personal definition of the Halting Problem question is that every
decider must test whether the HHH decider, when simulating the input,
would allow it to reach a return statement.
Yes.
Suppose I write a decider called GGG, and a function CC:
void CC(void)
{
if (GGG(CC)) { for (;;); }
else { return; }
}
So, the "correct" question is: does GGG(CC), correctly simulated by HHH, >>> reach its return statement?
I just empirically tested it: I changed GGG to HHH.
same result.
What? This is a new GGG; you must leave HHH alone.
Suppose that GGG(CC) is such that it returns 0. Thus, CC() reaches
the return statement, right?
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE ALWAYS TALKING ABOUT THE BEHAVIOR OF CC SIMULATED BY GGG
But you said:
The correct question is:
Does [whatever] correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state?
Moreover you agree with me that "every decider must test whether the HHH decider, when simulating the input, would allow it to reach a return statement."
So we must simulate CC() by HHH(CC). If that reaches its return
statement, the answer is accept/1/true.
CC calls GGG, which is distinct from HHH.
New deciders like GGG are allowed to exist, and we can put them
to the test against the "correct question".
Making a special exception for a cherry-picked HHH decider doesn't help. >>> All you are doing by redefining the question is casting doubt on your
work by raising the possibility that you're not writing about the real
Halting Problem.
The semantic property of the input finite string to GGG(CC)
is not halting.
We don't know that; it could be halting or not.
The correct ansewr is whether or not CC() reaches its final
return statement when correctly simulated by HHH(CC).
assert that GGG(CC) is halting or not without pining down the
definition of GGG.
For instance it could be this:
u32 GGG(Ptr P) { (void) P; return 0; }
or
u32 GGG(Ptr P) { (void) P; return 1; }
or other possibilities.
Try either of those as shown; do not edit GGG to HHH, or edit
CC to call HHH.
CC must be:
void CC(void) { if (GGG(CC) { for (;;); } else { return; } }
Since GGG isn't HHH, it doesn't have to conduct a simulation, but it
can, if you like.
No decider has ever been able to do anything
besides compute the mapping FROM ITS ACTUAL INPUT FINITE STRING
to the syntactic or semantic property specified by this INPUT
FINITE STRING. This mistake has apparently been perpetuated
since 1936.
I'm not saying otherwise. CC is a finite input to GGG, and
also to HHH.
On 09/09/2025 19:54, olcott wrote:
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The
behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever
about the Halting Problem.
It shows that the halting problem expectation
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Have you the slightest idea how ridiculous that sounds? Until you catch
up with what "halting" means, you're in no position to claim anything
about "the halting problem expectation".
to report on the behavior of things that it could
never see
HHH("dd.c"); /* SORTED. */
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
or did you keep perpetually ignoring this?
I have been over and over these same points thousands
and thousands of times.
On 9/9/2025 1:51 PM, Kaz Kylheku wrote:
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 12:30 PM, Kaz Kylheku wrote:
Your personal definition of the Halting Problem question is that every >>>> decider must test whether the HHH decider, when simulating the input,
would allow it to reach a return statement.
Yes.
Suppose I write a decider called GGG, and a function CC:
void CC(void)
{
if (GGG(CC)) { for (;;); }
else { return; }
}
So, the "correct" question is: does GGG(CC), correctly simulated by HHH, >>>> reach its return statement?
I just empirically tested it: I changed GGG to HHH.
same result.
What? This is a new GGG; you must leave HHH alone.
Suppose that GGG(CC) is such that it returns 0. Thus, CC() reaches
the return statement, right?
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE ALWAYS TALKING ABOUT THE BEHAVIOR OF CC SIMULATED BY GGG
But you said:
The correct question is:
Does [whatever] correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state?
CC correctly simulated by GGG cannot possibly
Moreover you agree with me that "every decider must test whether the HHH
decider, when simulating the input, would allow it to reach a return
statement."
So we must simulate CC() by HHH(CC). If that reaches its return
statement, the answer is accept/1/true.
CC calls GGG, which is distinct from HHH.
New deciders like GGG are allowed to exist, and we can put them
to the test against the "correct question".
Making a special exception for a cherry-picked HHH decider doesn't help. >>>> All you are doing by redefining the question is casting doubt on your
work by raising the possibility that you're not writing about the real >>>> Halting Problem.
The semantic property of the input finite string to GGG(CC)
is not halting.
We don't know that; it could be halting or not.
Every HHH/DD pair that has the same relationship as
the halting problem proof no matter how HHH/DD are
named DD specifies non-halting behavior.
The correct ansewr is whether or not CC() reaches its final
return statement when correctly simulated by HHH(CC).
That is just the same thing as HHH1(DD) and HHH(DD)
where the former does not have the HP pathological relationship.
assert that GGG(CC) is halting or not without pining down the
definition of GGG.
A non existent machine has no halt status value.
For instance it could be this:
u32 GGG(Ptr P) { (void) P; return 0; }
or
u32 GGG(Ptr P) { (void) P; return 1; }
or other possibilities.
Its a stupid idea (even though historically correct)
to say that a machine that ignores its input is a decider.
It is very misleading from an effective communication
perspective.
Try either of those as shown; do not edit GGG to HHH, or edit
CC to call HHH.
CC must be:
void CC(void) { if (GGG(CC) { for (;;); } else { return; } }
Since GGG isn't HHH, it doesn't have to conduct a simulation, but it
can, if you like.
No decider has ever been able to do anything
besides compute the mapping FROM ITS ACTUAL INPUT FINITE STRING
to the syntactic or semantic property specified by this INPUT
FINITE STRING. This mistake has apparently been perpetuated
since 1936.
I'm not saying otherwise. CC is a finite input to GGG, and
also to HHH.
It is a decider that actually decides something to
the same extent that I drive a dead cow to get to
the grocery store.
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The
behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about
the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see has always contradicted the definition
of Turing machine deciders that only compute the
mapping from their input finite strings.
On 9/9/2025 12:34 PM, Mike Terry wrote:
On 09/09/2025 16:26, joes wrote:
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would
stop running on its own without intervention. That this intervention is >>>> required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its own.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input >>>> is all that it can see.
Neither the name of a function nor the input on its own define anything. >>>
If we wanted to get HHH to examine the behavior of its caller then weWhat? DD called from main() definitely halts, otherwise HHH wouldn't
can do it this way.
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determines
that DD() executed from main() does not halt.
even run, and now HHH also "reports on its caller".
Yeah, it's strange - main() begins at 00002241 so PO's x86utm output for sure would have started
from that address. And yet somehow that's not showing in the output he posted, almost as though
PO has edited that output to trick everybody, thinking we're total idiots who wouldn't spot such a
trick! PO's output mysteriously starts at 00002249 - how did the processor get there!?
Conspiricy!! Conspiricy!!
----------------------- ---------------------
| | | |
| PUBLISH THE FULL | | WE DEMAND *ALL* |
| OUTPUT! | | THE TRACE |
| |----| |
-----------------------RAIN---------------------
| | THE | |
| | SWAMP! | |
| ----------- |
| | |
| | |
0/ O | \O
/| /|\| |\
/ \ / \ / \
Mike.
The full trace is not limited to what the directly
executed HHH(main) can actually see. The trace that I
provided is the trace this HHH(main) can actually see.
_DD()
[00002211] 55 push ebp
[00002212] 8bec mov ebp,esp
[00002214] 51 push ecx
[00002215] 6811220000 push 00002211
[0000221a] e802f4ffff call 00001621
[0000221f] 83c404 add esp,+04
[00002222] 8945fc mov [ebp-04],eax
[00002225] 837dfc00 cmp dword [ebp-04],+00
[00002229] 7402 jz 0000222d
[0000222b] ebfe jmp 0000222b
[0000222d] 8b45fc mov eax,[ebp-04]
[00002230] 8be5 mov esp,ebp
[00002232] 5d pop ebp
[00002233] c3 ret
Size in bytes:(0035) [00002233]
_main()
[00002241] 55 push ebp
[00002242] 8bec mov ebp,esp
[00002244] e8c8ffffff call 00002211
[00002249] 6841220000 push 00002241
[0000224e] e8cef3ffff call 00001621
[00002253] 83c404 add esp,+04
[00002256] 33c0 xor eax,eax
[00002258] 5d pop ebp
[00002259] c3 ret
Size in bytes:(0025) [00002259]
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [00002241][001039c0][00000000] 55 push ebp // main-01 [00002242][001039c0][00000000] 8bec mov ebp,esp // main-02
[00002244][001039bc][00002249] e8c8ffffff call 00002211 // call DD [00002211][001039b8][001039c0] 55 push ebp // DD-01 [00002212][001039b8][001039c0] 8bec mov ebp,esp // DD-02 [00002214][001039b4][00000000] 51 push ecx // DD-03 [00002215][001039b0][00002211] 6811220000 push 00002211 // push DD [0000221a][001039ac][0000221f] e802f4ffff call 00001621 // call HHH execution_trace:90909090
New slave_stack at:103a64
Begin Local Halt Decider Simulation Execution Trace Stored at:113a6c [00002211][00113a5c][00113a60] 55 push ebp // DD-01 [00002212][00113a5c][00113a60] 8bec mov ebp,esp // DD-02 [00002214][00113a58][00103a64] 51 push ecx // DD-03 [00002215][00113a54][00002211] 6811220000 push 00002211 // push DD [0000221a][00113a50][0000221f] e802f4ffff call 00001621 // call HHH execution_trace:113a6c
New slave_stack at:14e48c
[00002211][0015e484][0015e488] 55 push ebp // DD-01 [00002212][0015e484][0015e488] 8bec mov ebp,esp // DD-02 [00002214][0015e480][0014e48c] 51 push ecx // DD-03 [00002215][0015e47c][00002211] 6811220000 push 00002211 // push DD [0000221a][0015e478][0000221f] e802f4ffff call 00001621 // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000221f][001039b4][00000000] 83c404 add esp,+04 // DD-06 [00002222][001039b4][00000000] 8945fc mov [ebp-04],eax // DD-07 [00002225][001039b4][00000000] 837dfc00 cmp dword [ebp-04],+00 // DD-08 [00002229][001039b4][00000000] 7402 jz 0000222d // DD-09 [0000222d][001039b4][00000000] 8b45fc mov eax,[ebp-04] // DD-11 [00002230][001039b8][001039c0] 8be5 mov esp,ebp // DD-12 [00002232][001039bc][00002249] 5d pop ebp // DD-13 [00002233][001039c0][00000000] c3 ret // DD-14
[00002249][001039bc][00002241] 6841220000 push 00002241 // push main [0000224e][001039b8][00002253] e8cef3ffff call 00001621 // call HHH execution_trace:90909090
New slave_stack at:15e52c
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
Begin Local Halt Decider Simulation Execution Trace Stored at:16e534 [00002241][0016e524][0016e528] 55 push ebp // main-01 [00002242][0016e524][0016e528] 8bec mov ebp,esp // main-02 [00002244][0016e520][00002249] e8c8ffffff call 00002211 // call DD
[00002211][0016e51c][0016e524] 55 push ebp // DD-01 [00002212][0016e51c][0016e524] 8bec mov ebp,esp // DD-02 [00002214][0016e518][0015e52c] 51 push ecx // DD-03 [00002215][0016e514][00002211] 6811220000 push 00002211 // push DD [0000221a][0016e510][0000221f] e802f4ffff call 00001621 // call HHH execution_trace:16e534
New slave_stack at:1a8f54
[00002211][001b8f4c][001b8f50] 55 push ebp // DD-01 [00002212][001b8f4c][001b8f50] 8bec mov ebp,esp // DD-02 [00002214][001b8f48][001a8f54] 51 push ecx // DD-03 [00002215][001b8f44][00002211] 6811220000 push 00002211 // push DD [0000221a][001b8f40][0000221f] e802f4ffff call 00001621 // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002253][001039c0][00000000] 83c404 add esp,+04 // main-06 [00002256][001039c0][00000000] 33c0 xor eax,eax // main-07 [00002258][001039c4][00000018] 5d pop ebp // main-08 [00002259][001039c8][00000000] c3 ret // main-09
Number of Instructions Executed(22962) == 343 Pages
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
Yes. Did you bother to wonder about how foolish your statement sounds?
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem. By all
means use a simulator in your decider if it helps you decide, but there
will always be at least one program it can't *correctly* decide.
I have been over and over these same points thousands
and thousands of times.
Indeed you have, but they're still wrong.
On 09/09/2025 19:13, olcott wrote:
On 9/9/2025 12:34 PM, Mike Terry wrote:Right, this trace begins at the start.
On 09/09/2025 16:26, joes wrote:
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would >>>>> stop running on its own without intervention. That this
intervention is
required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its own. >>>>
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input.
sum(5,2) likewise only computes the sum of its input because its input >>>>> is all that it can see.
Neither the name of a function nor the input on its own define
anything.
If we wanted to get HHH to examine the behavior of its caller then we >>>>> can do it this way.What? DD called from main() definitely halts, otherwise HHH wouldn't
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determines >>>>> that DD() executed from main() does not halt.
even run, and now HHH also "reports on its caller".
Yeah, it's strange - main() begins at 00002241 so PO's x86utm output
for sure would have started from that address. And yet somehow
that's not showing in the output he posted, almost as though PO has
edited that output to trick everybody, thinking we're total idiots
who wouldn't spot such a trick! PO's output mysteriously starts at
00002249 - how did the processor get there!?
Conspiricy!! Conspiricy!!
----------------------- ---------------------
| | | |
| PUBLISH THE FULL | | WE DEMAND *ALL* |
| OUTPUT! | | THE TRACE |
| |----| |
-----------------------RAIN---------------------
| | THE | |
| | SWAMP! | |
| ----------- |
| | |
| | |
0/ O | \O
/| /|\| |\
/ \ / \ / \
Mike.
The full trace is not limited to what the directly
executed HHH(main) can actually see. The trace that I
provided is the trace this HHH(main) can actually see.
_DD()
[00002211] 55 push ebp
[00002212] 8bec mov ebp,esp
[00002214] 51 push ecx
[00002215] 6811220000 push 00002211
[0000221a] e802f4ffff call 00001621
[0000221f] 83c404 add esp,+04
[00002222] 8945fc mov [ebp-04],eax
[00002225] 837dfc00 cmp dword [ebp-04],+00
[00002229] 7402 jz 0000222d
[0000222b] ebfe jmp 0000222b
[0000222d] 8b45fc mov eax,[ebp-04]
[00002230] 8be5 mov esp,ebp
[00002232] 5d pop ebp
[00002233] c3 ret
Size in bytes:(0035) [00002233]
_main()
[00002241] 55 push ebp
[00002242] 8bec mov ebp,esp
[00002244] e8c8ffffff call 00002211
[00002249] 6841220000 push 00002241
[0000224e] e8cef3ffff call 00001621
[00002253] 83c404 add esp,+04
[00002256] 33c0 xor eax,eax
[00002258] 5d pop ebp
[00002259] c3 ret
Size in bytes:(0025) [00002259]
So let's pick this apart...
machine stack stack machine assembly >> address address data code language >> ======== ======== ======== ============== =============
[00002241][001039c0][00000000] 55 push ebp // main-01
[00002242][001039c0][00000000] 8bec mov ebp,esp // main-02
ok, so this is the start of DD() called from main()
[00002244][001039bc][00002249] e8c8ffffff call 00002211 // call DD >> [00002211][001039b8][001039c0] 55 push ebp // DD-01
[00002212][001039b8][001039c0] 8bec mov ebp,esp // DD-02
[00002214][001039b4][00000000] 51 push ecx // DD-03
[00002215][001039b0][00002211] 6811220000 push 00002211 // push DD >> [0000221a][001039ac][0000221f] e802f4ffff call 00001621 // call HHH >> execution_trace:90909090
New slave_stack at:103a64
Begin Local Halt Decider Simulation Execution Trace Stored at:113a6c
[00002211][00113a5c][00113a60] 55 push ebp // DD-01
[00002212][00113a5c][00113a60] 8bec mov ebp,esp // DD-02
[00002214][00113a58][00103a64] 51 push ecx // DD-03
[00002215][00113a54][00002211] 6811220000 push 00002211 // push DD >> [0000221a][00113a50][0000221f] e802f4ffff call 00001621 // call HHH >> execution_trace:113a6c
New slave_stack at:14e48c
[00002211][0015e484][0015e488] 55 push ebp // DD-01
[00002212][0015e484][0015e488] 8bec mov ebp,esp // DD-02
[00002214][0015e480][0014e48c] 51 push ecx // DD-03
[00002215][0015e47c][00002211] 6811220000 push 00002211 // push DD >> [0000221a][0015e478][0000221f] e802f4ffff call 00001621 // call HHH >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000221f][001039b4][00000000] 83c404 add esp,+04 // DD-06
[00002222][001039b4][00000000] 8945fc mov [ebp-04],eax // DD-07
[00002225][001039b4][00000000] 837dfc00 cmp dword [ebp-04],+00 // DD-08 >> [00002229][001039b4][00000000] 7402 jz 0000222d // DD-09
[0000222d][001039b4][00000000] 8b45fc mov eax,[ebp-04] // DD-11
[00002230][001039b8][001039c0] 8be5 mov esp,ebp // DD-12
[00002232][001039bc][00002249] 5d pop ebp // DD-13
[00002233][001039c0][00000000] c3 ret // DD-14
and now DD has reached its final ret instruction - IT HALTS!!
Now we see HHH deciding main()
[00002249][001039bc][00002241] 6841220000 push 00002241 // push main
[0000224e][001039b8][00002253] e8cef3ffff call 00001621 // call HHH
execution_trace:90909090
New slave_stack at:15e52c
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
Begin Local Halt Decider Simulation Execution Trace Stored at:16e534
[00002241][0016e524][0016e528] 55 push ebp // main-01
[00002242][0016e524][0016e528] 8bec mov ebp,esp // main-02
[00002244][0016e520][00002249] e8c8ffffff call 00002211 // call DD
ah, main calling DD() again - this bit is just like watching a video recording.
Wonder how it will go this time around...
[00002211][0016e51c][0016e524] 55 push ebp // DD-01
[00002212][0016e51c][0016e524] 8bec mov ebp,esp // DD-02
[00002214][0016e518][0015e52c] 51 push ecx // DD-03
[00002215][0016e514][00002211] 6811220000 push 00002211 // push DD >> [0000221a][0016e510][0000221f] e802f4ffff call 00001621 // call HHH >> execution_trace:16e534
New slave_stack at:1a8f54
[00002211][001b8f4c][001b8f50] 55 push ebp // DD-01
[00002212][001b8f4c][001b8f50] 8bec mov ebp,esp // DD-02
[00002214][001b8f48][001a8f54] 51 push ecx // DD-03
[00002215][001b8f44][00002211] 6811220000 push 00002211 // push DD >> [0000221a][001b8f40][0000221f] e802f4ffff call 00001621 // call HHH >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
and that's HHH deciding that main() never halts. It got it wrong, I can see main() halting just four more instructions down the page - doh!
Aha, I see - HHH is looking at the DD/HHH recursion when DD is called
from main(), and its "thinking" that DD isn't going to halt. But didn't
we see DD's trace earlier? YES! It's at the top of the trace above, and shows DD halting!
Look - HHH immediately above is seeing EXACTLY THE SAME TRACE as DD()
being called from main() at the top of your trace. Check the
instructions line by line - they're EXACTLY THE SAME, up to the point
HHH aborts its simulation. In the trace where its not aborted, DD continues and eventually halts, so whatever HHH is imagining, it's been smoking too much weed! :)
[00002253][001039c0][00000000] 83c404 add esp,+04 // main-06 >> [00002256][001039c0][00000000] 33c0 xor eax,eax // main-07
[00002258][001039c4][00000018] 5d pop ebp // main-08
[00002259][001039c8][00000000] c3 ret // main-09
Number of Instructions Executed(22962) == 343 Pages
Mike.
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The
behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about
the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see has always contradicted the definition
of Turing machine deciders that only compute the
mapping from their input finite strings.
I have no idea what you are blabbing about.
If you propose a halting decider H and implement it,
the resulting work is a string of 1s and 0s.
If someone takes that program, and wraps the diagonal template code
around it to produce D, that D is another, slightly longer string of 1s
and 0s.
This string of 1s and 0s can be fed to H as input.
H computes only using its input.
Nobody ever said otherwise.
Ironically, you are the one with a halting research apparatus in which potential deciders work with state othe than their input.
a pure function is something you learned from people this newsgroup over
the past bunch of years.
You have yet to adjust your code to
accordingly; you only pay lip service to pure computation, while
continuing to assert that you have empirically proven something.
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 1:51 PM, Kaz Kylheku wrote:
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 12:30 PM, Kaz Kylheku wrote:
Your personal definition of the Halting Problem question is that every >>>>> decider must test whether the HHH decider, when simulating the input, >>>>> would allow it to reach a return statement.
Yes.
Suppose I write a decider called GGG, and a function CC:
void CC(void)
{
if (GGG(CC)) { for (;;); }
else { return; }
}
So, the "correct" question is: does GGG(CC), correctly simulated by HHH, >>>>> reach its return statement?
I just empirically tested it: I changed GGG to HHH.
same result.
What? This is a new GGG; you must leave HHH alone.
Suppose that GGG(CC) is such that it returns 0. Thus, CC() reaches
the return statement, right?
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
WE ARE ALWAYS TALKING ABOUT THE BEHAVIOR OF CC SIMULATED BY GGG
But you said:
The correct question is:
Does [whatever] correctly simulated by HHH
ever reach its own simulated "return" statement
final halt state?
CC correctly simulated by GGG cannot possibly
GGG is not required to be simuulating at all; one possible GGG can be:
u32 GGG(Ptr P) { return 0; }
Moreover you agree with me that "every decider must test whether the HHH >>> decider, when simulating the input, would allow it to reach a return
statement."
So we must simulate CC() by HHH(CC). If that reaches its return
statement, the answer is accept/1/true.
CC calls GGG, which is distinct from HHH.
New deciders like GGG are allowed to exist, and we can put them
to the test against the "correct question".
Making a special exception for a cherry-picked HHH decider doesn't help. >>>>> All you are doing by redefining the question is casting doubt on your >>>>> work by raising the possibility that you're not writing about the real >>>>> Halting Problem.
The semantic property of the input finite string to GGG(CC)
is not halting.
We don't know that; it could be halting or not.
Every HHH/DD pair that has the same relationship as
the halting problem proof no matter how HHH/DD are
named DD specifies non-halting behavior.
No, HHH and DD are one specific pair, and that's it.
GGG is not HHH, and CC is not DD.
The correct ansewr is whether or not CC() reaches its final
return statement when correctly simulated by HHH(CC).
That is just the same thing as HHH1(DD) and HHH(DD)
where the former does not have the HP pathological relationship.
No it isn't quite because CC isn't DD. GGG/CC are a diagonal
pair, whereas HHH1/DD are not.
assert that GGG(CC) is halting or not without pining down the
definition of GGG.
A non existent machine has no halt status value.
For instance it could be this:
u32 GGG(Ptr P) { (void) P; return 0; }
or
u32 GGG(Ptr P) { (void) P; return 1; }
or other possibilities.
Its a stupid idea (even though historically correct)
to say that a machine that ignores its input is a decider.
No more stupid than the idea that a moderately complicated simulator is
a full-blown, production grade decider.
The HHH you have written does not decide anywhere near all
programs correctly.
We are concerned only with this: "can deciders evade the
classic Halting Proof and its trick".
For the present purposes, all we care about is whether GGG decides CC,
and nothing else. For, we can think about replacing GGG by a constant,
if we know which one. We imagine that the 0 or 1 can be calculated by a
more complicated procedure, but since we have only one test program we
care about, it doesn't matter.
Remember, you are the one who always cries "unfair" whenever someone
points out that none of your functions are a full blown decider.
Even if I agree with you that HHH is answering the correct question and
that HHH(DD) == 0 is correct (i.e. it has evaded the diagonal trick by answering a corrected question), HHH is far from a universal decider.
It is very misleading from an effective communication
perspective.
How so?
Try either of those as shown; do not edit GGG to HHH, or edit
CC to call HHH.
CC must be:
void CC(void) { if (GGG(CC) { for (;;); } else { return; } }
Since GGG isn't HHH, it doesn't have to conduct a simulation, but it
can, if you like.
No decider has ever been able to do anything
besides compute the mapping FROM ITS ACTUAL INPUT FINITE STRING
to the syntactic or semantic property specified by this INPUT
FINITE STRING. This mistake has apparently been perpetuated
since 1936.
I'm not saying otherwise. CC is a finite input to GGG, and
also to HHH.
It is a decider that actually decides something to
the same extent that I drive a dead cow to get to
the grocery store.
So, you are saying you can fix GGG by making it more complicated
than just return 0 or return 1?
OK, show how.
Do you mean by making GGG simulating, according to a sketch like:
u32 GGG(Ptr p)
{
u32 Status = 0;
Ptr Address_Of_H = (Ptr) HHH;
// initialize simulation
while (!Decide_Halting(..., HHH)) {
// single step simulation
}
// determine halting status to return
Status = ...
return Status;
}
We must use HHH as Address_Of_H in GGG, so that we are simulating
as if by HHH, to follow the "correct question".
The decision must look only for HHH in the execution traces;
it cannot be tailored to look for GGG.
We cannot change the halting question to suit every individual decider.
On 9/9/2025 2:50 PM, Kaz Kylheku wrote:
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The
behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about >>>> the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see has always contradicted the definition
of Turing machine deciders that only compute the
mapping from their input finite strings.
I have no idea what you are blabbing about.
You have no idea what computing the mapping is?
If you propose a halting decider H and implement it,
the resulting work is a string of 1s and 0s.
If someone takes that program, and wraps the diagonal template code
around it to produce D, that D is another, slightly longer string of 1s
and 0s.
This string of 1s and 0s can be fed to H as input.
H computes only using its input.
Nobody ever said otherwise.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct that
it is the input finite string that must be measured.
Instead of this people have assumed the the input finite
string that calls its own decider must have the same
behavior as the underlying machine.
As I have learned from 20,000 hours of primary research
in the last 21 years PATHOLOGICAL SELF-REFERENCE CHANGES
SEMANTICS.
hundreds of people on half a dozen different forums
have consistently totally ignored this for 21 years.
Ironically, you are the one with a halting research apparatus in which
potential deciders work with state othe than their input.
DD calls HHH(DD) in recursive simulation that is essentially
the same as mutual recursion.
void Y()
{
X();
}
void x()
{
Y();
}
It is like you don't understand mutual recursion.
(defun x () (y))** expr-1:1: warning: unbound function y
(defun y () (x))y
(x) ;;; instant fail** computation exceeded stack limit
(compile 'x)#<vm fun: 0 param>
(compile 'y)#<vm fun: 0 param>
(x) ;;; Ctrl-C after 10 seconds^C** intr <-- Ctrl-C break after 30 second
(disassemble 'x)data:
The whole business
about a decider having to work only with its input as
a pure function is something you learned from people this newsgroup over
the past bunch of years.
The simulation aspect is a pure function of its input.
You don't even seem to understand that.
You have yet to adjust your code to
accordingly; you only pay lip service to pure computation, while
continuing to assert that you have empirically proven something.
If we define a new computer science axiom that declares
that the control flow of X simulating Y is essentially
the same as X calling Y
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 2:50 PM, Kaz Kylheku wrote:
On 2025-09-09, olcott <polcott333@gmail.com> wrote:
On 9/9/2025 1:35 PM, Richard Heathfield wrote:
On 09/09/2025 19:03, olcott wrote:
Perpetual fallacy of equivocation error.
It is just like everyone in the group is
a brain dead moron on this one point.
WE ARE NEVER EVER TALKING ABOUT THE BEHAVIOR OF CC()
Maybe /you're/ not talking about the caller, but many of us are. The >>>>> behaviour of a decider that can't see the code it's deciding is not
really all that interesting, as it has nothing to say whatsoever about >>>>> the Halting Problem.
It shows that the halting problem expectation
to report on the behavior of things that it could
never see has always contradicted the definition
of Turing machine deciders that only compute the
mapping from their input finite strings.
I have no idea what you are blabbing about.
You have no idea what computing the mapping is?
I have no idea how you imagine that the requirement is lacking.
The only one who has ever flouted the requirement is you, in the
development of the x86utm and its collection of cheats.
If you propose a halting decider H and implement it,
the resulting work is a string of 1s and 0s.
If someone takes that program, and wraps the diagonal template code
around it to produce D, that D is another, slightly longer string of 1s
and 0s.
This string of 1s and 0s can be fed to H as input.
H computes only using its input.
Nobody ever said otherwise.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct that
it is the input finite string that must be measured.
Instead of this people have assumed the the input finite
string that calls its own decider must have the same
behavior as the underlying machine.
As I have learned from 20,000 hours of primary research
in the last 21 years PATHOLOGICAL SELF-REFERENCE CHANGES
SEMANTICS.
hundreds of people on half a dozen different forums
have consistently totally ignored this for 21 years.
Ironically, you are the one with a halting research apparatus in which
potential deciders work with state othe than their input.
DD calls HHH(DD) in recursive simulation that is essentially
the same as mutual recursion.
Did you not you chide me several days ago for conflating recursive simulation and recursion? (I was not). But it's okay for you, evidently.
Your various versions of the HHH decider do various goofy things
that do not stick to just analyzing the input.
void Y()
{
X();
}
void x()
{
Y();
}
It is like you don't understand mutual recursion.
I wrote a compiler which optimizes such a very pair to use no stack:
(defun x () (y))** expr-1:1: warning: unbound function y
x
(defun y () (x))y
(x) ;;; instant fail** computation exceeded stack limit
(compile 'x)#<vm fun: 0 param>
(compile 'y)#<vm fun: 0 param>
(x) ;;; Ctrl-C after 10 seconds^C** intr <-- Ctrl-C break after 30 second
(disassemble 'x)data:
syms:
0: y
code:
0: 8C000008 close t2 0 3 8 0 0 nil
1: 00000002
2: 00000000
3: 00000003
4: 9C000000 tail ;; <-- instruction prefix for tail call
5: 20000002 gcall t2 0
6: 00000000
7: 10000002 end t2
8: 10000002 end t2
instruction count:
5
entry point:
4
x
I understand that a mutual recursion involving a trip through simulations is running away just like mutual recursion and that can create an infinite tower of simulations. I'm not denying the infinite process behind it.
But what you don't understand is the subtlety that, separately from that recursive structure and infinite process, those simulations can potentially be
terminating, just fine!
A simulation doesn't become non-terminating just because the
simulator decides to pull the plug on it.
The whole business
about a decider having to work only with its input as
a pure function is something you learned from people this newsgroup over >>> the past bunch of years.
The simulation aspect is a pure function of its input.
You don't even seem to understand that.
You've not actually built anything which meets that requirement; none of the empirical experiments that you cite involve actual pure functions.
Nobody is waiting for you to build it because the Halting Theorem
assures that it's not possible; no combination of pure functions will demonstrate that the Halting Theorem is wrong.
You have yet to adjust your code to
accordingly; you only pay lip service to pure computation, while
continuing to assert that you have empirically proven something.
If we define a new computer science axiom that declares
that the control flow of X simulating Y is essentially
the same as X calling Y
But it isn't!
Only simulating Y /without stopping for any reason other than Y
reaching its return statement/ is essentially the same
as calling Y.
Simulating Y step by step, with the possibility of abandoning the simulation is
most definitely not essentially the same as calling Y.
It's like creating Y in its own coroutine, and such.
The ordinary caller of a function cannot dictate that the function will arbitrary stop partway through.
On 9/9/2025 2:19 PM, Richard Heathfield wrote:
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
Yes. Did you bother to wonder about how foolish your statement
sounds?
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem.
By all means use a simulator in your decider if it helps you
decide, but there will always be at least one program it can't
*correctly* decide.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct the
it is the input finite string that must be measured.
At least two people in this group have the capacity
to actually understand this.
What you do instead of verifying my reasoning
you
say to yourself blah, blah, blah didn't hear a
word you said.
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.
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.
On 10/09/2025 04:33, olcott wrote:[...]
✅ So to your question: No, it makes no difference. By construction, DD defeats any conceivable HHH.
+-------------------------------------------+
On 9/9/2025 3:52 PM, Mike Terry wrote:
On 09/09/2025 19:13, olcott wrote:
On 9/9/2025 12:34 PM, Mike Terry wrote:Right, this trace begins at the start.
On 09/09/2025 16:26, joes wrote:
Am Tue, 09 Sep 2025 10:00:01 -0500 schrieb olcott:
The directly executed DD() itself would never stop running unlessThe directly executed DD cannot be aborted because it isn't being
aborted at some point. Because of this we cannot say that DD() would >>>>>> stop running on its own without intervention. That this
intervention is
required indicates that even DD() cannot be said to actually halt.
simulated, nor does it need to be, because it stops running on its
own.
int sum(int x, int y){ return x + y; }And sum(x, y) = x - y does not compute the sum from that same input. >>>>> Neither the name of a function nor the input on its own define
sum(5,2) likewise only computes the sum of its input because its
input
is all that it can see.
anything.
If we wanted to get HHH to examine the behavior of its caller then we >>>>>> can do it this way.What? DD called from main() definitely halts, otherwise HHH wouldn't >>>>> even run, and now HHH also "reports on its caller".
int main()
{
DD();
HHH(main);
}
Now that HHH can see DD() executed from main HHH correctly determines >>>>>> that DD() executed from main() does not halt.
Yeah, it's strange - main() begins at 00002241 so PO's x86utm output
for sure would have started from that address. And yet somehow
that's not showing in the output he posted, almost as though PO has
edited that output to trick everybody, thinking we're total idiots
who wouldn't spot such a trick! PO's output mysteriously starts at
00002249 - how did the processor get there!?
Conspiricy!! Conspiricy!!
----------------------- ---------------------
| | | |
| PUBLISH THE FULL | | WE DEMAND *ALL* |
| OUTPUT! | | THE TRACE | >>>> | |----| |
-----------------------RAIN---------------------
| | THE | | >>>> | | SWAMP! | |
| ----------- |
| | |
| | |
0/ O | \O
/| /|\| |\
/ \ / \ / \
Mike.
The full trace is not limited to what the directly
executed HHH(main) can actually see. The trace that I
provided is the trace this HHH(main) can actually see.
_DD()
[00002211] 55 push ebp
[00002212] 8bec mov ebp,esp
[00002214] 51 push ecx
[00002215] 6811220000 push 00002211
[0000221a] e802f4ffff call 00001621
[0000221f] 83c404 add esp,+04
[00002222] 8945fc mov [ebp-04],eax
[00002225] 837dfc00 cmp dword [ebp-04],+00
[00002229] 7402 jz 0000222d
[0000222b] ebfe jmp 0000222b
[0000222d] 8b45fc mov eax,[ebp-04]
[00002230] 8be5 mov esp,ebp
[00002232] 5d pop ebp
[00002233] c3 ret
Size in bytes:(0035) [00002233]
_main()
[00002241] 55 push ebp
[00002242] 8bec mov ebp,esp
[00002244] e8c8ffffff call 00002211
[00002249] 6841220000 push 00002241
[0000224e] e8cef3ffff call 00001621
[00002253] 83c404 add esp,+04
[00002256] 33c0 xor eax,eax
[00002258] 5d pop ebp
[00002259] c3 ret
Size in bytes:(0025) [00002259]
So let's pick this apart...
machine stack stack machine assembly >>> address address data code language
======== ======== ======== ============== =============
[00002241][001039c0][00000000] 55 push ebp // main-01
[00002242][001039c0][00000000] 8bec mov ebp,esp // main-02
ok, so this is the start of DD() called from main()
[00002244][001039bc][00002249] e8c8ffffff call 00002211 // call DD >>> [00002211][001039b8][001039c0] 55 push ebp // DD-01
[00002212][001039b8][001039c0] 8bec mov ebp,esp // DD-02
[00002214][001039b4][00000000] 51 push ecx // DD-03
[00002215][001039b0][00002211] 6811220000 push 00002211 // push DD >>> [0000221a][001039ac][0000221f] e802f4ffff call 00001621 // call HHH >>> execution_trace:90909090
New slave_stack at:103a64
Begin Local Halt Decider Simulation Execution Trace Stored at:113a6c >>> [00002211][00113a5c][00113a60] 55 push ebp // DD-01
[00002212][00113a5c][00113a60] 8bec mov ebp,esp // DD-02
[00002214][00113a58][00103a64] 51 push ecx // DD-03
[00002215][00113a54][00002211] 6811220000 push 00002211 // push DD >>> [0000221a][00113a50][0000221f] e802f4ffff call 00001621 // call HHH >>> execution_trace:113a6c
New slave_stack at:14e48c
[00002211][0015e484][0015e488] 55 push ebp // DD-01
[00002212][0015e484][0015e488] 8bec mov ebp,esp // DD-02
[00002214][0015e480][0014e48c] 51 push ecx // DD-03
[00002215][0015e47c][00002211] 6811220000 push 00002211 // push DD >>> [0000221a][0015e478][0000221f] e802f4ffff call 00001621 // call HHH >>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000221f][001039b4][00000000] 83c404 add esp,+04 // DD-06
[00002222][001039b4][00000000] 8945fc mov [ebp-04],eax // DD-07
[00002225][001039b4][00000000] 837dfc00 cmp dword [ebp-04],+00 //
DD-08
[00002229][001039b4][00000000] 7402 jz 0000222d // DD-09
[0000222d][001039b4][00000000] 8b45fc mov eax,[ebp-04] // DD-11
[00002230][001039b8][001039c0] 8be5 mov esp,ebp // DD-12
[00002232][001039bc][00002249] 5d pop ebp // DD-13
[00002233][001039c0][00000000] c3 ret // DD-14
and now DD has reached its final ret instruction - IT HALTS!!
Now we see HHH deciding main()
[00002249][001039bc][00002241] 6841220000 push 00002241 // push mainah, main calling DD() again - this bit is just like watching a video
[0000224e][001039b8][00002253] e8cef3ffff call 00001621 // call HHH
execution_trace:90909090
New slave_stack at:15e52c
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
*This is the beginning of what HHH can actually see*
Begin Local Halt Decider Simulation Execution Trace Stored at:16e534 >>> [00002241][0016e524][0016e528] 55 push ebp // main-01
[00002242][0016e524][0016e528] 8bec mov ebp,esp // main-02
[00002244][0016e520][00002249] e8c8ffffff call 00002211 // call DD >>
recording.
Wonder how it will go this time around...
[00002211][0016e51c][0016e524] 55 push ebp // DD-01
[00002212][0016e51c][0016e524] 8bec mov ebp,esp // DD-02
[00002214][0016e518][0015e52c] 51 push ecx // DD-03
[00002215][0016e514][00002211] 6811220000 push 00002211 // push DD >>> [0000221a][0016e510][0000221f] e802f4ffff call 00001621 // call HHH >>> execution_trace:16e534
New slave_stack at:1a8f54
[00002211][001b8f4c][001b8f50] 55 push ebp // DD-01
[00002212][001b8f4c][001b8f50] 8bec mov ebp,esp // DD-02
[00002214][001b8f48][001a8f54] 51 push ecx // DD-03
[00002215][001b8f44][00002211] 6811220000 push 00002211 // push DD >>> [0000221a][001b8f40][0000221f] e802f4ffff call 00001621 // call HHH >>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
and that's HHH deciding that main() never halts. It got it wrong, I
can see main() halting just four more instructions down the page - doh!
Aha, I see - HHH is looking at the DD/HHH recursion when DD is called
from main(), and its "thinking" that DD isn't going to halt. But
didn't we see DD's trace earlier? YES! It's at the top of the trace
above, and shows DD halting!
Look - HHH immediately above is seeing EXACTLY THE SAME TRACE as DD()
being called from main() at the top of your trace. Check the
instructions line by line - they're EXACTLY THE SAME, up to the point
HHH aborts its simulation. In the trace where its not aborted, DD
continues and eventually halts, so whatever HHH is imagining, it's
been smoking too much weed! :)
[00002253][001039c0][00000000] 83c404 add esp,+04 // main-06
[00002256][001039c0][00000000] 33c0 xor eax,eax // main-07
[00002258][001039c4][00000018] 5d pop ebp // main-08
[00002259][001039c8][00000000] c3 ret // main-09
Number of Instructions Executed(22962) == 343 Pages
Mike.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
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:
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,
Please do not attempt to bluster your way through
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.
On 10/09/2025 01:16, olcott wrote:
On 9/9/2025 2:19 PM, Richard Heathfield wrote:
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
Yes. Did you bother to wonder about how foolish your statement sounds?
Clearly not.
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem. By all
means use a simulator in your decider if it helps you decide, but
there will always be at least one program it can't *correctly* decide.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct the
it is the input finite string that must be measured.
You argue that your "decider" can't see DD's awkward Turing Twist,
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().
On 9/10/2025 12:29 AM, Richard Heathfield wrote:
You argue that your "decider" can't see DD's awkward Turing Twist,
Just the opposite. I argue that everyone here
insists that HHH is supposed to ignore this twist
by having HHH(DD) report on the behavior of DD
after it has already aborted its simulation
instead of the steps that it must go through
to determine that this input must be aborted.
On 9/10/2025 12:54 AM, Richard Heathfield wrote:
On 10/09/2025 04:33, olcott wrote:<Input to LLM systems>
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().
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>
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates
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>Q1: What time is it? Yes or no (or undecidabe if none fits).
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>
On 9/10/2025 12:29 AM, Richard Heathfield wrote:
On 10/09/2025 01:16, olcott wrote:
On 9/9/2025 2:19 PM, Richard Heathfield wrote:
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
Yes. Did you bother to wonder about how foolish your statement sounds?
Clearly not.
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem. By all means use a simulator in your decider if it helps you decide, but there will always be at least one program it can't *correctly* decide.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct the
it is the input finite string that must be measured.
You argue that your "decider" can't see DD's awkward Turing Twist,
Just the opposite. I argue that everyone here
insists that HHH is supposed to ignore this twist
by having HHH(DD) report on the behavior of DD
after it has already aborted its simulation
instead of the steps that it must go through
to determine that this input must be aborted.
On 10/09/2025 17:33, olcott wrote:
<snip>
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates
LILO
Lies In, Lies Out.
You already conceded that DD is no business of HHH.
And your simulation is flawed and produces the wrong answer. You
carefully avoid giving your LLMs these facts.
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)
On Wed, 10 Sep 2025 11:33:38 -0500, olcott wrote:
On 9/10/2025 12:54 AM, Richard Heathfield wrote:
On 10/09/2025 04:33, olcott wrote:<Input to LLM systems>
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(). >>>
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>
To be valid, your input to LLMs must include tokens that cause the LLMs to predict tokens based on HHH being a Halting Problem halt decider.
/Flibble
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 returnNo (specified) value is possible.
*WHEN AN ACTUAL INPUT DOES THE OPPOSITE OF WHATEVER IT SAYS?*That is correct.
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
On Wed, 2025-09-10 at 11:31 -0500, olcott wrote:
On 9/10/2025 12:29 AM, Richard Heathfield wrote:
On 10/09/2025 01:16, olcott wrote:
On 9/9/2025 2:19 PM, Richard Heathfield wrote:Clearly not.
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word
*simulated*
Yes. Did you bother to wonder about how foolish your statement sounds? >>>
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem. By all >>>>> means use a simulator in your decider if it helps you decide, but
there will always be at least one program it can't *correctly* decide. >>>>>
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct the
it is the input finite string that must be measured.
You argue that your "decider" can't see DD's awkward Turing Twist,
Just the opposite. I argue that everyone here
insists that HHH is supposed to ignore this twist
by having HHH(DD) report on the behavior of DD
after it has already aborted its simulation
instead of the steps that it must go through
to determine that this input must be aborted.
Does HHH(DD) halts?
No, from POO logic, HHH(HHH(DD)) is pathological, the input, i.e. 'HHH(DD)' must be aborted.
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
On Wed, 2025-09-10 at 13:19 -0500, olcott wrote:
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
No (specified) value is possible.
*WHEN AN ACTUAL INPUT DOES THE OPPOSITE OF WHATEVER IT SAYS?*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
That is correct.
But if you claim a halt decider exists, then the bad case will exist.
On 9/10/2025 1:09 PM, wij wrote:
On Wed, 2025-09-10 at 11:31 -0500, olcott wrote:
On 9/10/2025 12:29 AM, Richard Heathfield wrote:
On 10/09/2025 01:16, olcott wrote:
On 9/9/2025 2:19 PM, Richard Heathfield wrote:
On 09/09/2025 20:13, olcott wrote:
On 9/9/2025 2:01 PM, Richard Heathfield wrote:
<snip>
You wrote: "Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running."
Yes I did. Did you bother to pay attention to the word *simulated*
Yes. Did you bother to wonder about how foolish your statement sounds?
Clearly not.
or did you keep perpetually ignoring this?
Yes. It has nothing whatsoever to do with the Halting Problem. By all
means use a simulator in your decider if it helps you decide, but there will always be at least one program it can't *correctly* decide.
If you actually understood that all Turing machine
deciders really do only report on a syntactic or
semantic property of their input finite string
then you would understand that I am correct the
it is the input finite string that must be measured.
You argue that your "decider" can't see DD's awkward Turing Twist,
Just the opposite. I argue that everyone here
insists that HHH is supposed to ignore this twist
by having HHH(DD) report on the behavior of DD
after it has already aborted its simulation
instead of the steps that it must go through
to determine that this input must be aborted.
Does HHH(DD) halts?
No, from POO logic, HHH(HHH(DD)) is pathological, the input, i.e. 'HHH(DD)' must be aborted.
The naive halting problem (like naive set theory)Does POOH take DD as an actual input (as real TM)?
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
The corrected halting problem (like ZFC) understandsYou don't even understand the basic logic, not to say ZFC. Wana test?
that the halt decider is required to compute the
mapping from its input finite string to the
actual behavior that this finite string actually
specifies.
This only makes a difference with the pathologicalHHH(HHH,DD) ... well, HHH calls its own decider (HHH), what do you say?
input where the input calls its own decider. Then
it makes a big difference.
On 9/10/2025 1:23 PM, wij wrote:
On Wed, 2025-09-10 at 13:19 -0500, olcott wrote:
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
No (specified) value is possible.
*WHEN AN ACTUAL INPUT DOES THE OPPOSITE OF WHATEVER IT SAYS?*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
That is correct.
But if you claim a halt decider exists, then the bad case will exist.
You have to read ALL the words that I saidWe know you like to play god, and now it seems the last resort, is it?
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
On 9/10/2025 12:19 PM, Richard Heathfield wrote:
On 10/09/2025 17:33, olcott wrote:
<snip>
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates
LILO
Lies In, Lies Out.
You already conceded that DD is no business of HHH.
The executable process DD() caller of HHH(DD)
is none of the busing of HHH.
The recursive
simulation behavior of the input finite string
of x86 machine code is all that HHH is concerned
with.
Your intentional use of the fallacy of
equivocation error seems to make you dishonest.
Answer: HHH(DD) should correctly return 0.
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
The corrected
halting problem (like ZFC) understands
that the halt decider is required to compute the
mapping from its input finite string to the
actual behavior that this finite string actually
specifies.
This only makes a difference with the pathological
input where the input calls its own decider. Then
it makes a big difference.
On 9/9/2025 2:37 PM, Kaz Kylheku wrote:[...]
Asking me to consider the behavior of a totally
undefined is like me telling you that some guy
went to some store and bought something.
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how to represent
a TM's Standard Description (SD) on a tape, and how a UTM can be
supplied with a tape bearing the SD of a TM and can execute that
program, thus proving that the existence of the program on tape is sufficient to execute the program.
On 9/10/2025 2:17 PM, Richard Heathfield wrote:
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how to
represent a TM's Standard Description (SD) on a tape, and how a
UTM can be supplied with a tape bearing the SD of a TM and can
execute that program, thus proving that the existence of the
program on tape is sufficient to execute the program.
Yet when we actually take into account that the
actual input actually does call its decider in
recursive simulation *THIS DOES CHANGE EVERYTHING*
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly
simulates
On 10/09/2025 22:11, olcott wrote:
On 9/10/2025 2:17 PM, Richard Heathfield wrote:
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how to
represent a TM's Standard Description (SD) on a tape, and how a UTM
can be supplied with a tape bearing the SD of a TM and can execute
that program, thus proving that the existence of the program on tape
is sufficient to execute the program.
Yet when we actually take into account that the
actual input actually does call its decider in
recursive simulation *THIS DOES CHANGE EVERYTHING*
No it doesn't.
a) You are on record as acknowledging that HHH is not a decider for DD because DD is none of HHH's business;
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
On 10/09/2025 22:11, olcott wrote:
On 9/10/2025 2:17 PM, Richard Heathfield wrote:
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how to
represent a TM's Standard Description (SD) on a tape, and how a UTM
can be supplied with a tape bearing the SD of a TM and can execute
that program, thus proving that the existence of the program on tape
is sufficient to execute the program.
Yet when we actually take into account that the
actual input actually does call its decider in
recursive simulation *THIS DOES CHANGE EVERYTHING*
No it doesn't.
a) You are on record as acknowledging that HHH is not a decider for DD
because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you that *you are a damned liar at this point*
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
On 10/09/2025 22:11, olcott wrote:
On 9/10/2025 2:17 PM, Richard Heathfield wrote:
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how
to represent a TM's Standard Description (SD) on a tape, and
how a UTM can be supplied with a tape bearing the SD of a TM
and can execute that program, thus proving that the existence
of the program on tape is sufficient to execute the program.
Yet when we actually take into account that the
actual input actually does call its decider in
recursive simulation *THIS DOES CHANGE EVERYTHING*
No it doesn't.
a) You are on record as acknowledging that HHH is not a decider
for DD because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you
that *you are a damned liar at this point*
DD() is none of the f-cking business of HHH
DD() is none of the f-cking business of HHH
DD() is none of the f-cking business of HHH
DD() is none of the f-cking business of HHH
All deciders are computable functions
that
compute THE mapping FROM THEIR INPUTS
FROM THEIR INPUTS FROM THEIR INPUTS FROM THEIR INPUTS
FROM THEIR INPUTS FROM THEIR INPUTS FROM THEIR INPUTS
FROM THEIR INPUTS FROM THEIR INPUTS FROM THEIR INPUTS
FROM THEIR INPUTS FROM THEIR INPUTS FROM THEIR INPUTS
DD() is not a f-cking input. What are you brain dead?
On 10/09/2025 22:37, olcott wrote:
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
On 10/09/2025 22:11, olcott wrote:
On 9/10/2025 2:17 PM, Richard Heathfield wrote:
On 10/09/2025 19:29, olcott wrote:
<snip>
The naive halting problem (like naive set theory)
requires that a halt decider to report on the
behavior of the direct execution of a machine
knowing full well that no Turing machine can
take another Turing machine as its actual input.
Not so. Turing's 1936 paper goes into some detail about how to
represent a TM's Standard Description (SD) on a tape, and how a UTM >>>>> can be supplied with a tape bearing the SD of a TM and can execute
that program, thus proving that the existence of the program on
tape is sufficient to execute the program.
Yet when we actually take into account that the
actual input actually does call its decider in
recursive simulation *THIS DOES CHANGE EVERYTHING*
No it doesn't.
a) You are on record as acknowledging that HHH is not a decider for
DD because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you
With me, sir? No, sir.
It has never been the job of any halt
decider to report on the behavior of
any directly executed machine such as DD()
On 9/10/2025 5:09 PM, Richard Heathfield wrote:
On 10/09/2025 22:37, olcott wrote:
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
a) You are on record as acknowledging that HHH is not a
decider for DD because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you
With me, sir? No, sir.
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.
On 10/09/2025 23:22, olcott wrote:
On 9/10/2025 5:09 PM, Richard Heathfield wrote:
On 10/09/2025 22:37, olcott wrote:
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
<snip>
a) You are on record as acknowledging that HHH is not a decider for >>>>> DD because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you
With me, sir? No, sir.
It has never been the job of any halt
decider to report on the behavior of
any directly executed machine such as DD()
Is that bullshit supposed to be how you "carefully separated the
executing process of DD() from the finite string of x86 code of DD",
then? I will certainly allow that you've posted those words a lot, but
they are clearly bullshit, so I just assumed you were doing your usual flannel job. It never occurred to me that you might actually believe them.
When you talk to LLMs, you don't show them a bunch of opcodes; you show
them this:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When you asked comp.lang.c about this code, you showed them C.
It is ***this code***, this C, that is at the centre of the question.
Your semisimulated machine code BS doesn't enter into it. Your "decider" ducks the very code it's supposed to address.
It is the job of every decider to decide whether the given program
halts. It has never been the job of any decider to make up a lot of
spurious bollocks as an excuse for ignoring most of the code and getting
the answer wrong. But you do you. If that;s the program you want, fine.
Just don't expect anyone else to agree with you.
It has always been the job of every halt
decider to examine a finite string machine
BS.
description to determine the behavior that
this finite string specifies such as the
finite string of x86 machine code of DD.
More BS.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is the code you're supposed to be deciding on, but for some bizarre
reason you keep finding new ways to say you can't. Well, quelle surprise
- we already know you can't. Nor can we. Nobody can. (We have a proof,
in case you didn't know.)
Yes it seems that you are still a damned liar.
You snipped the most important parts.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates
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.
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
by disabling the abort code.
Are you ONLY
a liar or can you tell the truth?
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
a) You are on record as acknowledging that HHH is not a decider for DD
because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you that *you are a damned liar at this point*
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
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.
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
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
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.
$
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.
So you are saying that analyzing DD is
the job of HHH and is not the job of DD:
is_job_of(X, Y) AND NOT is_job_of(X, Y)
which has the form
P AND NOT P
which is a falsehood.
On 2025-09-10, olcott <polcott333@gmail.com> 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
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.
DD is built on HHH.
Therefore DD is now a different DD.
With the abort code disabled, DD becomes a non-halting DD.
HHH(DD) fails to terminate; and so HHH has not correctly decided
anything.
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.
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
When you disable the abort code, that changes the behavior
of HHH.
and proves that this
*would never stop running unless aborted* criteria is met:
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:
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.
DD simulated by HHH includes DD calling HHH(DD)
in recursive emulation that *is* non-halting.
DD simulated by HHH1 does not include DD
calling HHH1(DD) in recursive emulation.
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> 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
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.
and proves that
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 4:27 PM, Richard Heathfield wrote:
a) You are on record as acknowledging that HHH is not a decider for DD
because DD is none of HHH's business;
I have carefully separated the executing process of DD()
from the finite string of x86 code of DD so many times
with you that *you are a damned liar at this point*
Ah, speaking of which, I previously asked you to identify what you think comprises DD. What is in that string?
Can you list all the bill of materials that you believe go into DD,
and be sure not to include anything that you do not believe to be part
of DD?
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.
DD simulated by HHH includes DD calling HHH(DD)
in recursive emulation that *is* non-halting.
DD simulated by HHH1 does not include DD
calling HHH1(DD) in recursive emulation.
called in recursive emulation
DOES NOT EQUAL
not called in recursive emulation.
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.)
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,069 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 83:24:25 |
| Calls: | 13,728 |
| Calls today: | 3 |
| Files: | 186,961 |
| D/L today: |
5,822 files (1,537M bytes) |
| Messages: | 2,416,639 |